1. Field of the Invention
This invention relates to Public Key Infrastructures (PKI), and more specifically to personal revocation authority in a PKI.
2. Background Information
A public key infrastructure (PKI) is a collection of servers and software that enables an organization, company, or enterprise to distribute and manage thousands of unique public/private cryptographic keys in a manner that allows users to reliably determine the identity of the owner of each public/private key pair. When each member of an enterprise has a unique key, paper-based business processes may be transitioned to an online, electronic equivalent. Public/private key pairs have the property that for any given public key there exists one and only one private key, and vice versa. Public key cryptography (i.e., the ability to publicly distribute the encryption key) can be used to digitally sign documents. If a particular message can be decrypted using one member of the key pair, then the assumption is that the message must have been encrypted using the other member. If only one person knows the key used to perform the encryption of a document in the first place, then the recipients that can decrypt the document can be sure that the sender of the document must be that person.
However, for a digital signature to be meaningful, the recipient of an object signed with the digital signature must first be able to reliably determine the owner and integrity of the key used to sign the object. Public infrastructures accomplish this using an electronic document called a digital certificate. Certificates may contain information identifying the owner of the key pair, the public component of the pair, and the period of time for which the certificate is valid. The certificate may also identify technical information about the key itself, such as the algorithm used to generate the key, and the key length. Certificates are generated by organizations, companies, or enterprises that are responsible for verifying the identity of individuals (or in some instances organizations) to which certificates are issued. The certifying organization is known as a certificate authority. The certificate authority signs each certificate using a private key known only to the certificate authority itself. This allows users of the PKI to verify both the integrity of the certificate and the identity of the authority that issued it. By issuing a certificate, a certificate authority is stating that it has verified that the public key that appears in the certificate (and, by extension, the corresponding private key) belongs to the individual listed in the certificate. The integrity with which the registration process operates is, therefore, of great importance. The process must provide mechanisms for reliably identifying the individual and for verifying that the public key listed in the certificate belongs to that individual.
FIG. 1 shows a block diagram of an example PKI system architecture. Current PKIs that provide strong authentication of user identity accomplish this via the use of a local registration authority officer (LRAO) 12. LRAO 12 operates at a work station or server platform 14 that runs a local registration authority software application 16. Server platform 14 may be any known computing device that may serve as a server, e.g. computer, workstation, etc. The local registration authority application 16 interfaces to other server platforms that may contain applications such as a certificate authority application 18, a registration authority application 20, and/or a key recovery authority application 22. Each application may be on the same server platform, or on separate individual server platforms 14. A user 10, that is using or desires access to the PKI system architecture, accesses the system via a web browser 23 on a client platform 24. A hardware token 26, such as a smart card, may also be operably connecteable to client platform 24. Typically in current systems, user 10 presents a photo I.D. to the local registration authority officer 12 in order to authenticate the user's identity. Local registration authority officer 12 then uses workstation 14 and local registration authority application 16 to signal a registration authority application 20 to register new user 10 in the system. Local registration authority application 16 may be off-the-shelf product software that comes typically bundled with a certificate authority application 18, registration authority application 20, and key recovery authority 22 software.
A public/private key pair is generated by either the local registration authority application 16 or the registration authority application 20 (depending on products chosen and depending on how they've been configured). The public key is sent to certificate authority application 18 to be signed, thereby, generating a certificate for new user 10. A backup copy of the private key may also be sent to key recovery authority application 22, however, normally the private key is kept on a token 26, or at client platform 24 by user 10. Once the public key is sent to a certificate authority 18 and signed, a user signature certificate is generated and provided to a local registration authority server. Local registration authority officer 12 copies the certificate (including the private key) onto a floppy disk, hardware token, or other storage medium, and then provides the user signature certificate and private key to the user.
If an enterprise uses signature certificates, then the signature certificates must be kept secure. One way to increase the security of a signature certificate is to make it very easy for users to revoke and renew a certificate if there is even a hint that the certificate may have been compromised. Further, certificates stored on devices such as smart cards, floppy disks, or hardware tokens may be misplaced. Alternatively, a certificate stored on a hard drive or removable media could become corrupted, and a backup copy might not be available. In either of these cases, the original user 15, signature certificate must be revoked for security reasons, and a new certificate generated for the user. Moreover, in cases of suspected misconduct by a user, one of the first enterprise officers that may become aware of the possible misconduct is often the user's manager. In such cases, the manager may wish to revoke a user's signature certificate immediately.
One would not want to allow just any individual to revoke a signature certificate. Ideally, it may be preferred that only the owner of the certificate be able to revoke their certificate. However, in order to authenticate the identity of the user during the revocation process, the user must present the user signature certificate. After the user is authenticated, the user may be allowed to revoke the certificate. In the case of a lost certificate, a user has no way of authenticating his identity during the revocation process.
Current PKI operating models require a registration authority (RA) which is a process that not only registers a user, but also revokes digital certificates of the user when they are no longer needed. Registration Authorities may be specialized enterprise officers who must be contacted in such cases. This is expensive, in that it requires additional labor via specialized officers, and slow, in that the manager must locate and explain the situation to the officer. Depending on the implementation, the registration authority process can be very impractical for very large PKI implementations.
A registration authority might be a system administrator or security control officer at some geographic location. A registration authority which performs a revocation of certificates may be referred to as a local revocation authority (LRA). Revocation requests are submitted by a user via some method (e.g., paper, email, web, etc.) to the LRA. The revocation requests are queued for work off within some specified time frame.
Current public key infrastructures for revoking digital certificates have some problems. First, for large organizations, the cost to implement systems similar to that shown in FIG. 1 are high due to the need for multiple local registration authority officers to handle the large number of users that may reside at various locations. Generally, certificate revocation requests are submitted via some method (paper, email, web, etc.) to the local registration authority. The certificate revocation requests are queued for working off by the local registration authority officers. Current systems are inefficient because request queues will be subject to human intervention. The normal certificate revocation process involves actions by the requester (i.e., user) and the local registration authority. After some time and effort, the requester receives notification of revocation of the digital certificate. This time may be dependent on the number of requests in the queue and/or the efficiency of the local registration authority officers. Thus, current systems and processes are less secure because of the potential lag in time between a revocation request and deletion of the certificate from the PKI directory.
Moreover, current systems are less secure because a relationship between the requester and the local registration authority officer does not necessarily exist and, therefore, presents opportunity for an intruder to exploit. In addition, current systems are less secure since without a manager of the user (or some other individual who may personally know the user), in the process flow, there is no definitive proof who the pin and password (required for generation of new digital certificates) given to the user is issued to.
Therefore, a good PKI implementation must provide a secure and timely method to revoke digital certificates when there is a threat of compromise, a certificate is lost, or when situations necessitate that an individual's access be denied. Further, it is desired to reduce the labor and time necessary to revoke digital certificates.
The revocation and replacement process must not be too easy, otherwise hackers may perpetrate a denial of service attack by randomly revoking user's certificates. Currently, there has generally been no way to revoke and replace a certificate so that the process is both easy and secure.
Therefore, a need exists for an efficient, speedy, and secure revocation process for revoking digital signature certificates of users in a PKI.